1. Field
The present disclosure relates to bridging access to a memory space across pre-boot and runtime phases and, more particularly, to accessing the memory utilizing a separate pre-boot memory accessor and a runtime accessor.
2. Background Information
Typically, the operation of computer or processing systems (hereafter, “computer”) may be divided into two stages, pre-boot and runtime. The pre-boot process or phase often comprises starting or resetting a computer. When first turned on (cold boot) or reset/reboot (warm boot), a computer executes the firmware that loads and starts the computer's more complicated operating system and prepares it for use. Thus, the computer can be said to pull itself up by its own bootstraps. The runtime process or phase often occurs after the pre-boot phase and includes the execution of an operating system and other user applications. The runtime phase is typically the phase that users interact with the computer. Thus, the computer can be said to being running application programs.
Typically, during pre-boot, the computer is first powered on and has very limited capabilities because the volatile memory contains random data and no operating system is running. To begin the pre-boot phase, the processor is often reset to a known state and instructions found at a pre-defined location are executed. Traditionally, this pre-defined location is mapped to a non-volatile memory or firmware referred to as a Basic Input/Output System (BIOS). The BIOS often includes several low-level procedures to control the initialization of the hardware components that comprise the computer. Because of the historical limitations of early computers, the BIOS generally operated in what is known as “real mode.” In real mode, the computer may only execute one program at a time and can access no more than 1 MB of volatile memory. Modern operating systems, on the other hand, often run in “protected mode.” Protected mode allows the computer to run multiple programs substantially simultaneously, referred to as multi-taking, and there is essentially no limit to the amount of volatile memory that may be accessed.
During pre-boot, the BIOS generally confirms that the computer's hardware components, such as, for example, the CPU, memory and various add-on cards, are functioning properly. In addition, these hardware components may be configured and initialized during the pre-boot phase. Often an application may, for example, desire to collect information about a hardware component during the pre-boot phase and supply the information to a runtime phase application or driver. In this context, a driver or device driver is a specialized program that augments an operating system's capability to support a hardware component.
Traditionally, runtime applications have had substantially unfettered access to the same portions of memory as the pre-boot applications. Therefore, passing information between the pre-boot and runtime phases was relatively trivial. For example, one technique for bridging information between the two phases may include the following steps. The pre-boot application may reserve a portion of volatile memory to store the information. The pre-boot application may store a pointer to this portion of volatile memory at a predefined location. Because the pre-boot phase is often limited to accessing a maximum of 1 MB of volatile memory, this predefined location is typically below that limit. During the runtime phase, the driver may directly access the pointer and, subsequently, access the information. However, this technique involves insecure and potentially uncontrolled access to the system memory.
More current systems limit the access runtime applications have to the portions of memory the pre-boot applications have. The access of runtime applications is often limited and controlled by the operating system. Therefore, the technique above, of placing a pointer within the first MB of volatile memory, will not work. The operating system will often not allow a runtime application to make a direct access to a random address in volatile memory. A need therefore exists for a technique or apparatus to address the issue of bridging a memory between pre-boot and runtime phases.